Have you considered using local spans instead? the idea of injecting alternate names for ocsql to use through context seems both tedious and error prone. With local spans you can create a parent span around all database operations / transactions that you want to identify as a particular business logic operation.

Yes, I was thinking of local spans, but that seemed extra verbose and less useful.

Generally I want to span only external communications (db calls, http client requests, event publishing, etc...) because internal calculations usually are of much less latency magnitude. That's why ocsql serves a good purpose by automatically creating a span when external call happens.

Higher level business task may or may not invoke db call (can be short-circuited with cache), so if I create a span on parent business task I'll have a bunch of spans that are not relevant to db observability. They are not useful to me.

If I create span just before calling db I would need an abstraction (that understands current business context) to use instead of direct sql.DB/Tx access. But then, having this abstraction to create spans, why would I need ocsql?

I'm using zpages/tracez quite often to get an current overview of external communications. It does not show spans in a tree, but rather as a flat list grouped by span name. sql:query being produced by a variety of different statements does not have enough cardinality to be helpful outside tree representation. Context gives best flexibility to pass optional additional information about some specific tasks (same as *http.Request and context introduced in census-instrumentation/opencensus-go#796).